home *** CD-ROM | disk | FTP | other *** search
/ C/C++ Users Group Library 1996 July / C-C++ Users Group Library July 1996.iso / vol_100 / 138_01 / bu.doc < prev    next >
Text File  |  1985-03-09  |  14KB  |  302 lines
  1.  
  2.  
  3. Ian Ashdown
  4. byHeart Software
  5. 2 - 2016 West First Avenue
  6. Vancouver, B.C. V6J 1G8
  7. Tel: (604) 738-5927
  8.  
  9.  
  10.  
  11.  
  12.  
  13.         Archiving Files With CP/M-80 and CP/M-86
  14.         ----------------------------------------
  15.  
  16.           Copyright 1984 Ian E. Ashdown
  17.             byHeart Software
  18.  
  19.  
  20.  
  21.  
  22.  
  23. *****************************************************************
  24. *                                *
  25. * NOTE: This manuscript was published in the January 1985 issue *
  26. *    of Doctor Dobb's Journal. It may be reproduced for    *
  27. *    personal, non-commercial use only, provided that the    *
  28. *    above copyright notice is included in all copies.    *
  29. *    Copying for any other use without previously obtaining    *
  30. *    the written permission of the author is prohibited.    *
  31. *                                *
  32. *****************************************************************
  33.  
  34.  
  35.  
  36.     If you use CP/M-80 Versions 2.x or CP/M-86, you know the
  37. problem well - sitting there at two in the morning trying to
  38. remember which files you worked on so you can copy them to a
  39. backup disk. If you have a hard disk in your system, the problem
  40. can be an acute pain - which of several hundred files did you
  41. update or otherwise modify during your marathon programming
  42. session?
  43.  
  44.     The ideal solution would be to have a utility program
  45. that somehow determines which files have been changed on a disk
  46. and automatically copy them to a backup disk. This procedure,
  47. known as "incremental backup", is superior by far to the usual
  48. methods of either relying on your memory (at two in the morning?)
  49. or copying the entire disk.
  50.  
  51.     Although Digital Research's documentation for their
  52. CP/M-80 and CP/M-86 operating systems give no indication that a
  53. file is in any manner marked when it is written to or renamed, it
  54. is nevertheless possible to implement an incremental backup
  55. utility exactly as described above - the "ideal solution". BU is
  56. one example of such an implementation.
  57.  
  58.  
  59. THEORY AND PRACTICE
  60. -------------------
  61.  
  62.     For a detailed explanation of the inner workings of BU,
  63. you should read the comments accompanying the source code. These
  64. have been written to give even the novice C programmer a clear
  65. understanding of what is going on each step of the way. What
  66. follows is a general description that covers only the salient
  67. features of BU from a user's viewpoint.
  68.  
  69.     The CP/M-80 Version 2 Interface Guide's description for
  70. BDOS Service 30 (Set File Attributes) states that the file
  71. attribute bit t3-prime is "reserved for future system expansion".
  72. However, if you use a disk utility to set it true in the file's
  73. directory entry, you will find that the BDOS resets it to false
  74. (zero) whenever the directory entry is changed. Since this means
  75. that the file has been opened, written to and closed (or else
  76. renamed) by the BDOS, t3-prime is apparently an undocumented
  77. attribute bit that indicates when a file has been updated.
  78.  
  79.     This behaviour is not an artifact of some other process
  80. that cannot be relied on - DRI added a very similiar feature to
  81. their multiuser MP/M 2 operating system called the "Archive"
  82. attribute. The version of PIP.COM supplied with MP/M 2 features
  83. an "A" option, which causes PIP to copy only those files that
  84. have their Archive bits set false. After copying each file, PIP
  85. sets the bit true. It seems logical then that in writing CP/M-80
  86. v2.x and CP/M-86, DRI intended to rewrite its version of PIP to
  87. include an "A" option, but for whatever reason never got around
  88. to doing so. This leaves the user to come up with a utility that
  89. takes advantage of this orphaned attribute.
  90.  
  91.     There are a variety of such utilities available,
  92. including one in the public domain and at least two commercial
  93. products. What BU has to offer is that it is written in C, thus
  94. presenting you with the opportunity to easily customize it to
  95. your particular needs. The source code has been profusely
  96. commented for precisely this reason.
  97.  
  98.     BU accepts command lines of the following form:
  99.  
  100.         BU x[:afn] y [-AFHQSn]
  101.  
  102.         where x = drive name of disk to be backed up
  103.               y = drive name of backup disk
  104.  
  105.         and the optional arguments are:
  106.  
  107.              -A   All files, regardless of status
  108.              -F   Fast copy (without verification)
  109.              -H   Hard disk (files may be split)
  110.              -Q   Query each file before backup
  111.              -S   System attribute copied to backup
  112.              -n   Backup USER 'n' files only (0-31)
  113.              afn  Any legal CP/M ambiguous fileref
  114.               (can only be used with -n option)
  115.  
  116.     If the above is a bit confusing, some examples may help
  117. in explaining the various options:
  118.  
  119.     BU a b          Copy updated files in all user areas
  120.               from drive A: to drive B:
  121.     BU c a -f          Copy updated files in all user areas
  122.               from drive C: to drive A: without
  123.               verification of copied files
  124.     BU a:file.typ m -5      Copy file A:FILE.TYP (user area 5) to
  125.               same user area on drive M:
  126.     BU a:file*.t? c -0q      Copy any files in user area 0 matching
  127.               ambiguous file reference A:FILE*.t? to
  128.               the same user area on drive C:. The
  129.               operator is queried before each file is
  130.               copied - answering 'y' or 'Y' for "Yes"
  131.               results in the file being archived;
  132.               anything else results in the file being
  133.               skipped.
  134.     BU b a -ah          All files from all user areas are
  135.               copied from drive B: to drive A:. If
  136.               BU runs out of backup disk space while
  137.               copying a file, the file will be split
  138.               across two disks.
  139.     BU a b -a -s      All files from all user areas are
  140.               copied from drive A: to drive B:. Those
  141.               files with the System attribute set are
  142.               copied as System files to drive B:.
  143.               (Note that the dash options can be
  144.               separated.)
  145.  
  146.     A fair amount of the code involved in BU has to do with
  147. defensive programming - always assume that the user will make a
  148. mistake. The command line is validated as thoroughly as possible.
  149. Any errors detected are displayed with an appropriate message,
  150. along with the above explanation of what command lines are valid.
  151.  
  152.     Once in operation and assuming no options have been
  153. selected or ambiguous file reference specified, the program will
  154. scan the directory of the disk in drive "x", note which files
  155. have been changed since the last time BU was run on that disk,
  156. and then copy only those files to the disk in drive "y". Existing
  157. files with the same fileref and user number on the backup disk
  158. are automatically erased.
  159.  
  160.     Since the new files are backup copies, each one is read
  161. after it is written and verified character by character with the
  162. original file.  All available memory is used to buffer the data
  163. for disk read and write operations so that BU can copy and verify
  164. as quickly as possible. Once the new file has been fully
  165. verified, its file attributes are set to "directory" (DIR) and
  166. "read-only" (R/O) to ensure that it can be displayed in a
  167. directory listing of the backup disk, and that it cannot be
  168. accidentally erased.
  169.  
  170.     If the combined size of the files to be backed up exceeds
  171. the available space on the backup disk, BU will take one of two
  172. actions, depending on whether or not the -H option has been
  173. selected. In the default mode, BU will stop when it runs out of
  174. disk space and erase the current partially-written backup file.
  175. It will then ask the operator to insert a fresh disk in the
  176. backup drive. When this is done, BU will continue to copy files
  177. to the new disk.
  178.  
  179.     The -H option is intended primarily for use with hard
  180. disks, where the size of the files may exceed the capacity of the
  181. backup disks. When BU runs out of disk space with this option
  182. active, it will close the current partially-written backup file
  183. and set its attributes to DIR and R/O, then ask the operator to
  184. insert a fresh disk in the backup drive. When done, BU will open
  185. a sequentially-numbered fileref (e.g. - "FILE.TYP" would become
  186. "FILE--01.TYP") and continue writing the current file to this new
  187. backup file from where it left off. The file will in effect be
  188. split across two or more backup disks, with no wasted disk space.
  189.  
  190.     Reassembling these split files is quite simple. In
  191. principle, you need only open the first file for write access,
  192. use "lseek()" to find its end, open the second file